Standards Specific to Transactions and Business Rules

Transactions

1. Make sure new transactions are defined with the correct rule type.  

• Example: Don’t define Policy-Financial activities as Policy-Document activities.  

• Names should not have spaces and should be camel case.  

• Use the same icons for like transactions across products via TransactionCosmetics.

2. Call for ValuationXML"TYPE="VALUATION”

• This is the initial call to VALUATION, not each individual call to retrieve individual items.

• This will ensure that valuation is not called multiple times for one transaction.  It could be called multiple times if the call was allowed in CopyBooks.
   

Attached Business Rules

1. Attached business rules each have their own general structure.

2. With the exception of TransactionCosmetics and SummaryFields, business rules attached to transactions need to be included in the TransactionBusinessRulePacket or they will not be processed by the transaction.

3. TransactionCosmetics should not appear in the TransactionBusinessRulePacket.

4. SummaryFields are optional in the TransactionBusinessRulePacket.  Keep in mind that it will be processed regardless, as long as it is attached to the transaction.

5. The rules listed in the TransactionBusinessRulePacket are processed top to bottom.

6. Assuming all these rules apply to a transaction, the order of the rules should be as follows:

• TransactionTimes (not in V9.0)

• ValidateExpressions (not in V9.0)

• GeneratePendingRequirements (not in V9.0)

• DeliveryRequirements (not in V9.0)

• CopyToPolicyFields

• CopyToSegmentFields

• CopyToRoleFields (not in V9.0)

• UpdateRecords (not in V9.0)

• ShadowPendingActivity

• StatusChange

7. Do not attach a ReportFileTypes business rule to Policy-Financial transactions.

CopyBook and Function Business Rules

CopyBooks

1. The naming standard for creating a CopyBook rule is CopyBook-CopyBookName.

• This is when you are not copying a complete transaction section.

2. Keep names generic so that they can be used across plans, but clear enough to identify how the CopyBook can be used.

3. Configure comments in a CopyBook to define all required inputs and important outputs so it is easier to use.

4. Configure comments in a transaction that identify the CopyBook configuration that is being used.  

5. When creating a CopyBook, perform analysis to determine how flexible the CopyBook should be so it is most useful to other plans or business needs.  

6. Remember that putting certain tags into a CopyBook will restrict how it is used.

7. Using the following tags may make it impossible to reuse a CopyBook:

• EffectiveDate

• Allocations

• Suspense

• Valuation

• Call for Valuation "TYPE="VALUATION” should be in the calling transaction.  

• Fields and math should be analyzed prior to placing in a CopyBook.

Functions

1. Naming standard: Function-FunctionName.

2. All functions must be global.

3. Currently, overrides are NOT supported for functions.  

4. Currently, calling CopyBooks with overrides are NOT supported for functions.  All CopyBooks called by a function must be global.

5. Prior to the function call, initialize all needed or useful outputs.  If an output will not be used, it does not need to be initialized.

6. Use functions when calculation or functionality can be broken out into discrete and logical pieces.

7. Use functions when the majority of MathVariables do not need to be stored or used outside of the function.

8. When possible use functions in the place of CopyBooks.

9. Initialize all meaningful parameters and return variables prior to the function call.  A meaningful parameter is a field that will be used in any manner after the function is called such as math, spawns, validations or passed to another function.

Miscellaneous Best Practices

1. Do not use XML shortcut element syntax like <EffectiveDate/>.  

2. Each opening tag should have a closing tag. <EffectiveDate></EffectiveDate>.

3. When trying to use Issue State within a transaction, do not use a SQL query.  

• Define a variable with TYPE=”FIELD” and use Policy:IssueStateCode for efficiency.

4. During configuration development use <!-- TBD.&ldots;   -- > for comments indicating future work will be done. Also, indicate the configuration that is missing.

5. Use comments in a business rule or transaction to explain functionality.

6. DebugScript Info:

• Debug Script attribute should be removed from the MathVariable tag before migrating a rule into production to keep AsEngineMath from getting too large.

• If the Debug Script is set to any value other than null (even = No), a record will be written to AsEngineMath.

• The system-level mathdebuglevel can also control whether or not a record is written to AsEngineMath.

• Debug Script does not work for Function Rules.